Seven Prompts To Sell It. None Of Them Builds It.
Start with the praise, because this card has earned some.
Seven prompts for turning AI workflows into a paid service, posted in the comments. Read them and count the restraint clauses. Prompt 1 wants opportunities “where automation saves meaningful time while keeping necessary human review“. Prompt 2 asks for “validation, human review, outputs, storage, errors, and fallback actions” and adds “Protect sensitive data and flag decisions that require human verification“. Prompt 3 wants “limitations” in the offer and says “avoid unverified promises“. Prompt 5 says “prioritize relevant prospects over mass outreach“. Prompt 7 asks you to compare before and after “without overstating causation“.
And prompt 4 contains the single most responsible instruction we have quoted in this entire series: build the demo “using fictional data” and “clearly label it as an illustrative demo—not a real client case study.”
That is somebody deliberately heading off the standard sin of this genre – the invented case study – inside a prompt. All seven carry at least one clause that makes the work harder and the claims smaller. For a post whose headline contains a dollar figure and the word BREAKING, that is a remarkable gap between the advertisement and the goods. The prompts are better than their own hook.
So this post is not about what is wrong with them. It is about what is missing between them.
Lay the seven out in order: find the opportunity → design the architecture → package the offer → build a demo → find clients → onboard them → measure the value.
That is a complete go-to-market. Read it again and ask a plain question: at which step does the automation actually get built and tested on the client’s real data?
It does not. Step 2 produces an architecture, which is a document. Step 4 produces a demo on fictional data, which is a mockup – honestly labelled as one, to the card’s credit. Step 6 onboards a paying client. And then the seven prompts end.
The post this article is about
Read the original post: “7 prompts to turn useful workflows into a service”
The seven prompts are posted in the comments beneath. The tables below quote all seven as written, read on 10 October 2026.
What exists after each step
Here is the sequence with one column added: the artefact you can actually point at when that step is finished.
Diagram: seven steps, seven documents
| Step | What the prompt produces | Is it a working thing? | Who has taken on risk by now |
|---|---|---|---|
| 1. Find opportunities | A list of ten candidate workflows with bottlenecks and risks | No – research | Nobody |
| 2. Design the workflow | An architecture: triggers, AI steps, validation, fallbacks | No – a design document | Nobody |
| 3. Package the service | An offer with deliverables, timeline, limitations, pricing | No – a sales document | Nobody |
| 4. Build a demo | A before-and-after demo on fictional data, labelled as illustrative | No – a mockup, and the card says so plainly | Nobody, because it is labelled honestly |
| 5. Find target clients | Five client types with pain signals and qualifying questions | No – a prospect list | Nobody |
| 6. Create onboarding | Discovery, access requirements, security, approvals, handoff | No – but a client has now said yes | You have. And so has the client |
| 7. Measure value | A framework for baseline metrics and before/after comparison | No – a measurement plan, for a thing that does not exist yet | Both of you |
| The missing step | The automation itself, running on the client’s real data, with the failures found | This is the only step that would be | — |
Read down the third column. Every single answer is no. Seven prompts produce seven documents – a good list, a good design, a good offer, a good mockup, a good prospect list, a good onboarding plan and a good measurement framework. Not one line of the thing you are selling.
And look at row six. That is where the money and the obligation arrive. You can complete all seven prompts and be in a signed engagement for something you have not yet built once.
This is the same shape we keep finding from different directions – a card of a hundred tools that all did the producing stage, a case study that counted the build and never used it. Here the gap is unusual because it is in the middle rather than at the end.
All seven, with the clause that holds each one back
Column 3 is the reason this card is worth taking seriously. Every prompt has one.
| Prompt | Quoted as written | Its restraint clause | Our note – read 10 October 2026 |
|---|---|---|---|
| 1. Find Automation Opportunities | “Analyze [INDUSTRY] and identify 10 repetitive workflows that could benefit from AI or automation. For each, show the current process, bottleneck, inputs, outputs, risks, and potential solution…” | “Prioritize practical opportunities where automation saves meaningful time while keeping necessary human review“ | Good opening move. Asking for risks alongside opportunities is rare. Note it analyses an industry in the abstract – you will need to replace that with workflows you have actually watched someone do |
| 2. Design the Workflow | “Turn [WORKFLOW] into a detailed AI automation architecture. Define triggers, inputs, AI steps, validation, human review, outputs, storage, errors, and fallback actions.” | “Protect sensitive data and flag decisions that require human verification“ | The strongest prompt on the card. Nine architectural elements, four of which (validation, human review, errors, fallbacks) are about things going wrong. That is how a real system is specified |
| 3. Package the Service | “Turn [AUTOMATION] into a clear client service offer. Define the problem, deliverables, implementation stages, access requirements, timeline, support, limitations, and pricing.” | “Keep it simple for non-technical buyers and avoid unverified promises“ | “Limitations” sits in the deliverables list, which is unusual and correct. Note that “pricing” is one bullet among nine – nothing here derives the headline’s $500 from anything |
| 4. Build a Demo | “Create a realistic demo of [AUTOMATION] using fictional data. Show the before-and-after workflow, sample inputs, processing steps, outputs, and interface.” | “Clearly label it as an illustrative demo—not a real client case study“ | The best single instruction in this whole series of cards. Fake case studies are the standard failure of this genre and this prompt forbids one in advance |
| 5. Find Target Clients | “Identify 5 ideal client types for [AUTOMATION]. For each, define pain signals, relevant processes, decision-makers, qualification questions, and personalization opportunities.” | “Prioritize relevant prospects over mass outreach“ | An explicit anti-spam clause in a client-acquisition prompt. “Qualification questions” is the useful bit – it assumes you will turn some people away |
| 6. Create Onboarding | “Build a client onboarding process for an AI automation project. Include discovery questions, access requirements, workflow documentation, security, success criteria, testing, approvals, responsibilities, and handoff.” | “security… approvals… responsibilities“ | “Access requirements” is doing heavy lifting. This step is where a client hands you credentials to their systems – treat that as the serious moment it is, not a form to fill in |
| 7. Measure Automation Value | “Create a measurement framework for [AUTOMATION]. Define baseline metrics, time saved, error rates, throughput, quality, review time, and business outcomes.” | “Show how to compare before and after implementation without overstating causation“ | “Without overstating causation” is a sophisticated clause to find on a marketing card. It is asking you not to claim credit for an improvement you merely stood next to. Also: this must be run before you start, not after – a baseline measured afterwards is not a baseline |
Selling before building is normal. Not knowing you are doing it is not.
To be fair to the card: selling a service before you have built the specific instance is how consulting has always worked. Nobody builds a bespoke automation on spec and then goes looking for someone who wants it. You sell the capability, then you deliver.
The question is whether you have the capability. And that is exactly what these seven prompts cannot tell you, because every one of them produces a document, and documents come out looking equally confident whether or not you can do the thing.
Here is where it actually goes wrong in practice, and none of it is visible from a well-written architecture:
The client’s data is not like your demo data. Prompt 4 was honest that the demo is fictional – and fictional data is clean. Real data has duplicate records, three date formats, a column somebody renamed in 2023, and four hundred rows that break the rule you built the logic on.
The access takes longer than the build. Prompt 6 lists “access requirements” as one bullet. In practice it is two weeks of waiting for somebody’s IT to approve an API key, and it happens after you have quoted a timeline.
The edge cases are the job. Prompt 2 is excellent on this – it asks for errors and fallback actions in the design. But designing a fallback and discovering, on live data, the nine cases you did not design for are different activities, and only one of them is in the seven.
And the human review you promised has to be somebody’s actual job. Prompt 1 and prompt 2 both insist on human review, correctly. Who does it? At what hour? What happens when they are on holiday? That is an operational commitment, and it belongs in the offer in prompt 3.
The eighth prompt the card needed
Written in the same style as the other seven, and in the same restrained voice, here is what is missing – plus what to check before you let it near a client.
| Stage | What to do | Why it belongs before step 6, not after | Done when |
|---|---|---|---|
| 8a. Build it once, for yourself | Run the architecture from prompt 2 against your own messy data, end to end | You find out whether you can do it while nobody is paying you | It completes a full cycle without you touching it |
| 8b. Break it deliberately | Feed it an empty file, a wrong format, a duplicate, a value ten times too large, and a record in another language | The fallbacks from prompt 2 are a design until something has actually fallen back | Every one fails safely and tells you why |
| 8c. Time the real thing | Measure how long a run takes, including the human review you promised | Prompt 3 asks for a timeline and prompt 7 for baselines. Both need a number you measured, not estimated | You can quote hours without guessing |
| 8d. Name the reviewer | Decide who performs the human review, when, and what they are allowed to reject | Both prompt 1 and prompt 2 require human review. An unassigned requirement is not a safeguard | A person’s name is in the offer |
| 8e. Write the failure clause | What happens if the automation is wrong? Who notices, how fast, who pays | Prompt 3 asks for “limitations”. This is the limitation that matters | It is in the offer in plain language |
| 8f. Take the baseline | Measure the current, manual process before you change anything | Prompt 7 is written last and must be run first. A baseline taken afterwards is a guess | You have the “before” number in writing, agreed with the client |
Item 8f is worth the whole table. Prompt 7 is numbered last and has to happen first. You cannot measure “time saved” unless somebody wrote down how long it took before – and once the automation is running, the honest “before” number is gone forever and you are left estimating it, which is precisely the overstated causation that prompt 7 warns against.
Four honest caveats
This is the most restrained money-making card we have covered. Seven prompts, seven clauses that make the work harder and the claims smaller. Human review, sensitive data, unverified promises, fictional demo data, no mass outreach, no overstated causation. Whoever wrote these has clearly delivered client work and been burned, because those are not the instincts of somebody who has only sold courses about it.
The $500 is a hook, and we should say so plainly. It appears once, in the headline, and in none of the seven prompts. Prompt 3 mentions “pricing” as one bullet among nine and derives nothing. That is not dishonest – it is a number to make you stop scrolling – but do not treat it as a finding. What you can charge depends on the workflow, the client and whether it works.
Selling before building is not a scam. We want to be careful here. Every agency and freelancer on earth sells a capability and then delivers it. The warning is narrower: these seven produce only documents, and a confident document is not evidence that you can build the thing. Build one for yourself first, for free, and then the offer is backed by something.
And we have not run them. Everything above is read off the prompts as written. We have not used them to find a client or deliver a project, and the eighth-step table is our own construction, not a tested methodology.
The one-line version
Seven prompts, in order: find it, design it, package it, demo it, sell it, onboard it, measure it. Every one of them produces a document, and none of them produces a working automation. The hole is in the middle, between the labelled mockup in step 4 and the signed client in step 6.
So add step 8 and move step 7. Build it once on your own messy data, break it on purpose, time it, name the human reviewer, write down what happens when it is wrong – and take the baseline before you change anything. That last one is the card’s own step 7, run at the start instead of the end.
And keep the clauses. “Human review.” “Protect sensitive data.” “Avoid unverified promises.” “Fictional data, clearly labelled.” Those seven sentences are the real asset on this card, and they are the part most people will delete when they paste the prompts in, because they make everything slower.
Learning a lot does not make anyone good. Doing a lot does. Running seven prompts produces seven documents in an afternoon. Building the automation once, badly, on your own data is a worse afternoon and the only one that tells you whether you have a service.
If you want to be held to that, we run a free challenge at BANI Academy. There is no barrier to entry – you commit a small fee that is refunded when you finish, and the only requirement is that you actually do the work for the length of the challenge.
Before you quote anyone: have you built this once, for yourself, on real data? Tell us in the comments under the original post – and if the honest answer is no, that is the next thing to do rather than the next prompt to run.
More on building a channel for a global audience at mmoyoutube.com.
